Syslog, CDR and Debug Parameters

The syslog, CDRand debug parameters are described in the table below.

Syslog, CDR and Debug Parameters

Parameter

Description

Syslog

'Enable Syslog'

configure troubleshoot > syslog > syslog

[EnableSyslog]

Determines whether the device sends logs and error messages (e.g., CDRs) generated by the device to a syslog server.

[0] Disable (default)
[1] Enable

Note:

If you enable syslog, you also need to configure the syslog server's address (IP address or FQDN), using the [SyslogServerIP] parameter.
Syslog messages may increase the network traffic.
To configure syslog SIP message logging levels, use the [GwDebugLevel] parameter.
By default, logs are also sent to the RS-232 serial port. On how to establish serial communication with the device, refer to the Installation Manual.

'Syslog Interface'

configure troubleshoot > syslog > syslog-interface

[SyslogInterface]

Assigns an IP Interface from the IP Interfaces table (see Configuring IP Network Interfaces) for communication with the primary syslog server.

By default, the OAMP interface is used.

Note: The IP address version (IPv4 or IPv6) of the IP Interface and the syslog server's address must be the same.

'Syslog Server IP'

configure troubleshoot > syslog > syslog-ip

[SyslogServerIP]

Defines the address (IP address or FQDN) of the computer on which the primary syslog server is running. The syslog server is an application designed to collect the logs and error messages generated by the device.

The default IP address is 0.0.0.0.

Note:

To configure secondary syslog servers, see Configuring Secondary Syslog Servers.

'Syslog Server Port'

configure troubleshoot > syslog > syslog-port

[SyslogServerPort]

Defines the UDP port of the primary syslog server.

The valid range is 0 to 65,535. The default port is 514.

Note: To configure secondary syslog servers, see Configuring Secondary Syslog Servers.

'Syslog Protocol'

configure troubleshoot > syslog > syslog-protocol

[SyslogProtocol]

Defines the transport protocol for communicating with the primary syslog server.

[0] UDP (default)
[1] TCP
[2] TLS

Note: 

If you configure the parameter to TLS, you also need to select a TLS Context (certificate), as described in Configuring the Primary Syslog Server Address.
To configure secondary syslog servers, see Configuring Secondary Syslog Servers.

'Syslog TLS Context'

configure troubleshoot > syslog > syslog-tls-context-name

[SyslogTLSContext]

Assigns a TLS Context when the TLS transport protocol is used for communication with the syslog server (primary and secondary servers).

For configuring TLS Contexts, see Configuring TLS Certificate Contexts.

'Log Severity Level'

log-level

[SyslogLogLevel]

Defines the minimum severity level of messages included in the syslog message that is generated by the device.

The specified severity level and all higher severity levels are included in the syslog message. For example, if you configure the parameter to Alert, the syslog will include messages with Alert severity level and messages with Emergency severity level. The severity levels are listed below from highest to lowest severity.

[0] Emergency
[1] Alert
[2] Critical
[3] Error
[4] Warning
[5] Notice (default)
[6] Info [not recommended]
[7] Debug [not recommended]

Note:

It's recommended to leave the syslog severity level at its default setting (i.e., Notice) to prevent excessive utilization of the device's resources. Changing severity level is typically done only by AudioCodes Support for debugging.
If you configure the parameter to Info [not recommended] or Debug [not recommended], the parameter returns to default value (Notice) after a device restart.

[EnableConsoleLog]

Enables the device to send the syslog messages to the serial console (over the device's physical serial interface). This may be useful, for example, if you no longer have network access to the device and you would like to perform diagnostics.

[0] = (Default) Disable
[1] = Enable

Note:

For the parameter to take effect, a device restart is required.
Even when enabled, the device continues sending the syslog messages to the configured remote syslog server.

HTTP Client Requests and Response

configure troubleshoot > logging settings > enable-http-client-dbg-msg

[EnableHttpClientDbgMsg]

Enables the device to log (syslog) HTTP requests and responses (like CURL's verbose data) received from HTTP clients.

[0] = (Default) Disable
[1] = Enable

Note: To log only specific HTTP clients (based on URL filters), see the [HTTPLogFilter] parameter.

configure troubleshoot > logging settings > http-log-filter

[HTTPLogFilter]

Defines the HTTP clients whose requests and responses you want the device to log, based on the presence of specific strings within their URLs.

The valid value is a string of up to 256 characters. You can configure the parameter with multiple strings, where each string is separated by a space (e.g., 'url1 url2 url3'). The value must be enclosed by single quotation marks (' '). The default is an empty string (' '), which means that the device logs requests and responses from all HTTP clients.

Note: To enable the logging of HTTP client requests and responses, see the [EnableHttpClientDbgMsg] parameter.

CDR

'CDR Syslog Server IP Address'

configure troubleshoot > cdr > cdr-srvr-ip-adrr

[CDRSyslogServerIP]

Defines the address (IPv4 or IPv6, or FQDN) of the syslog server to where the device sends the CDRs.

By default, no address is defined. If not configured, the device sends the CDRs (with the syslog messages) to the syslog server configured by the [SyslogServerIP] parameter. If you configure an address for the [CDRSyslogServerIP] parameter, the device sends the CDRs only to this CDR syslog server and not to the syslog server configured by the [SyslogServerIP] parameter.

Note:

The CDRs are sent to UDP port 514 (default syslog port).
To enable the device to send CDRs, you also need to enable syslog (see Enabling Syslog).

'Call-End CDR SIP Reasons Filter'

configure troubleshoot > cdr > call-end-cdr-sip-reasons-filter

[CallEndCDRSIPReasonsFilter]

Defines SIP release cause codes that if received for the call, the devicedoesn't sent Call-End CDRs for the call.

The valid value is 300 through to 699. You can configure the parameter with multiple codes using a comma to separate them (e.g., 301,400,404). You can also use "xx" to denote a range (e.g., 3xx).

'Call-End CDR Zero Duration Filter'

configure troubleshoot > cdr > call-end-cdr-zero-duration-filter

[CallEndCDRZeroDurationFilter]

Enables the device to not send Call-End CDRs if the call's duration is zero (0).

[0] Disable (default)
[1] Enable

'CDR Report Level'

configure troubleshoot > cdr > cdr-report-level

[CDRReportLevel]

Enables media and signaling-related CDRs to be sent to a syslog server and defines the call stage at which they are sent.

[0] None = (Default) CDRs are not used.
[1] End Call = CDR is sent to the syslog server at the end of each call.
[2] Start & End Call = CDR report is sent to syslog at the start and end of each call.
[3] Connect & End Call = CDR report is sent to syslog at connection and at the end of each call.
[4] Start & End & Connect Call = CDR report is sent to syslog at the start, at connection, and at the end of each call.

Note:

For the SBC application: The parameter enables only signaling-related CDRs. To enable media-related CDRs for SBC calls, use the [MediaCDRReportLevel] parameter.
The CDR Syslog message complies with RFC 3164 and is identified by: Facility = 17 (local1) and Severity = 6 (Informational).
This mechanism is active only when syslog is enabled (i.e., the parameter [EnableSyslog] is set to [1]).

'Media CDR Report Level'

configure troubleshoot > cdr > media-cdr-rprt-level

[MediaCDRReportLevel]

Enables media-related CDRs of SBC calls to be sent to a syslog server and defines the call stage at which they are sent.

[0] None = (Default) No media-related CDR is sent.
[1] End Media = Sends a CDR only at the end of the call.
[2] Start & End Media = Sends a CDR once the media starts. In some calls it may only be after the call is established, but in other calls the media may start at ringback tone. A CDR is also sent upon termination (end) of the media in the call.
[3] Update & End Media = Sends a CDR when an update occurs in the media of the call. For example, a call starts and a ringback tone occurs, a re-INVITE is sent for a fax call and as a result, a CDR with the MediaReportType field set to "Update" is sent, as the media was changed from voice to T.38. A CDR is also sent upon termination (end) of the media in the call.
[4] Start & End & Update Media = Sends a CDR at the start of the media, upon an update in the media (if occurs), and at the end of the media.

Note:

The parameter is applicable only to the SBC application.
To enable CDR generation as well as enable signaling-related CDRs, use the CDRReportLevel parameter.

'REST CDR Report Level'

configure system > cdr > rest-cdr-report-level

[RestCdrReportLevel]

Enables signaling-related CDRs to be sent to a REST server and defines the call stage at which they are sent.

[0] None = (Default) CDRs are not sent.
[1] End Call = CDRs are sent at the end (SIP BYE) of each call.
[2] Start & End Call = CDRs are sent at the start (SIP INVITE) and end of each call.
[3] Connect & End Call = CDRs are sent at call connection (200 OK) and end of each call.
[4] Start & End & Connect Call = CDRs are sent at the start, connection, and end of each call.
[5] Connect Only = CDRs are sent at call connection.

Note:

To specify the REST server, use the [RestCdrHttpServer] parameter.
For the device to generate CDRs, you must enable syslog messaging (see the [EnableSyslog] parameter).
CDRs are sent in JSON format.

'REST CDR HTTP Server'

configure system > cdr > rest-cdr-http-server

[RestCdrHttpServer]

Defines the REST server (configured in the Remote Web Services table) to where the device sends CDRs through REST API.

The valid value is a string (i.e., name of the REST server). By default, no value is defined.

Note:

For the ini file and CLI command, the parameter value is case sensitive.
To enable CDR generation for the REST server, see the [RestCdrReportLevel] parameter.
The REST server is configured in the Remote Web Services table (see Configuring Remote Web Services).

'Call Success SIP Reasons'

configure troubleshoot > cdr > call-success-sip-reasons

[CallSuccessSIPReasons]

Defines the SIP response code that you want the device to consider as a call success, which is indicated by the optional 'Call Success' field in the sent CDR. This parameter overrides the device's default behavior of how it considers calls a success or failure based on SIP responses.

The valid value is string of up to 128 characters to represent SIP response codes (e.g., 404). You can configure the parameter with multiple response codes, whereby each code is separated by a comma without spaces before or after (e.g., 404,408,406). You can also configure a range of responses using the "xx" wildcard (e.g., 4xx,502). By default, no value is defined.

Note: If an overlap of a SIP response occurs between the configured 'Call Success SIP Reasons' and 'Call Failure SIP Reasons' parameters, the device uses the parameter that is configured with the specific response code, instead of the parameter configured with the range ("xx"). For example, if you configure the 'Call Success SIP Reasons' parameter with "404,5xx" and the 'Call Failure SIP Reasons' parameter with "502", for 502 responses, the device uses the settings of the 'Call Failure SIP Reasons' parameter only. In other words, a call with SIP response code 502 is considered as a call failure.

'Call Failure SIP Reasons'

call-failure-sip-reasons

[CallFailureSIPReasons]

Defines the SIP response codes that you want the device to consider as call failure, which is indicated by the optional 'Call Success' field in the sent CDR. This parameter overrides the device's default behavior of how it considers calls a success or failure based on SIP responses.

The valid value is string of up to 128 characters to represent SIP response codes (e.g., 486). You can configure the parameter with multiple response codes, whereby each code is separated by a comma without spaces before or after (e.g., 486,408,406). You can also configure a range of responses using the "xx" wildcard (e.g., 4xx,502). By default, no value is defined.

Note: If an overlap of a SIP response occurs between the configured 'Call Success SIP Reasons' and 'Call Failure SIP Reasons' parameters, the device uses the parameter that is configured with the specific response code, instead of the parameter configured with the range ("xx"). For example, if you configure the 'Call Success SIP Reasons' parameter with "486,5xx" and the 'Call Failure SIP Reasons' parameter with "502", for 502 responses, the device uses the settings of the 'Call Failure SIP Reasons' parameter only. In other words, a call with SIP response code 502 is considered as a call failure.

'Call Success Internal Reasons'

call-success-internal-reasons

[CallSuccessInternalReasons]

Defines the internal response codes (generated by the device) that you want the device to consider as call success, which is indicated by the optional 'Call Success' field in the sent CDR. This parameter overrides the device's default behavior of how it considers calls a success or failure based on internally responses.

The valid value is string of up to 128 characters to represent internal response codes (e.g., 851). You can configure the parameter with multiple response codes, whereby each code is separated by a comma without spaces before or after (e.g., 851,320). You can also configure a range of responses using the "xx" wildcard (e.g., 8xx,320). By default, no value is defined.

Note:

For a list of the internal response codes, see the 'Termination Reason' [410] CDR field in CDR Field Description.
If an overlap of a SIP response occurs between the configured 'Call Success SIP Reasons' and 'Call Failure SIP Reasons' parameters, the device uses the parameter that is configured with the specific response code, instead of the parameter configured with the range ("xx"). For example, if you configure the 'Call Success SIP Reasons' parameter with "320,8xx" and the 'Call Failure SIP Reasons' parameter with "851", for 851 responses, the device uses the settings of the 'Call Failure SIP Reasons' parameter only. In other words, a call with response code 851 is considered as a call failure.

'Call Failure Internal Reasons'

call-failure-internal-reasons

[CallFailureInternalReasons]

Defines the internal response codes (generated by the device) that you want the device to consider as call failure, which is indicated by the optional 'Call Success' field in the sent CDR. This parameter overrides the device's default behavior of how it considers calls a success or failure based on internally responses.

The valid value is string of up to 128 characters to represent internal response codes (e.g., 851). You can configure the parameter with multiple response codes, whereby each code is separated by a comma without spaces before or after (e.g., 851,320). You can also configure a range of responses using the "xx" wildcard (e.g., 8xx,320). By default, no value is defined.

Note:

For a list of the internal response codes, see the 'Termination Reason' [410] CDR field in CDR Field Description.
If an overlap of a SIP response occurs between the configured 'Call Success SIP Reasons' and 'Call Failure SIP Reasons' parameters, the device uses the parameter that is configured with the specific response code, instead of the parameter configured with the range ("xx"). For example, if you configure the 'Call Success SIP Reasons' parameter with "320,8xx" and the 'Call Failure SIP Reasons' parameter with "851", for 851 responses, the device uses the settings of the 'Call Failure SIP Reasons' parameter only. In other words, a call with response code 851 is considered as a call failure.

'No User Response Before Connect'

no-user-response-before-connect

[NoUserResponseBeforeConnectSuccess]

Defines if the device considers a call as a success or failure when the internal response (generated by the device) "GWAPP_NO_USER_RESPONDING" (18) is received before call connect (SIP 200 OK).

[0] Call Failure
[1] Call Success (default)

'No User Response After Connect'

no-user-response-after-connect

[NoUserResponseAfterConnectSuccess]

Defines if the device considers a call as a success or failure when the internal response (generated by the device) "GWAPP_NO_USER_RESPONDING" (18) is received after call connect (SIP 200 OK).

[0] Call Failure (default)
[1] Call Success

'Call Transferred before Connect'

call-transferred-before-connect

[CallTransferredBeforeConnectSuccess]

Defines if the device considers a call as a success or failure when the internal response (generated by the device) "RELEASE_BECAUSE_CALL_TRANSFERRED" (807) is generated before call connect (SIP 200 OK).

[0] Call Failure (default)
[1] Call Success

'Call Transferred after Connect'

call-transferred-after-connect

[CallTransferredAfterConnectSuccess]

Defines if the device considers a call as a success or failure when the internal response (generated by the device) "RELEASE_BECAUSE_CALL_TRANSFERRED" (807) is generated after call connect (SIP 200 OK).

[0] Call Failure
[1] Call Success (default)

'VoIP Debug Level'

configure troubleshoot > syslog > debug-level

[GwDebugLevel]

Enables syslog debug reporting and logging level.

[0] No Debug = (Default) Debug is disabled and syslog messages are not sent.
[1] Basic = Sends debug logs of incoming and outgoing SIP messages.
[5] Detailed = Sends debug logs of incoming and outgoing SIP message as well as many other logged processes.

configure system > cdr > non-call-cdr-rprt

[EnableNonCallCdr]

Enables creation of CDR messages for non-call SIP dialogs (such as SUBSCRIBE, OPTIONS, and REGISTER).

[0] = (Default) Disable
[1] = Enable

Note: The parameter is applicable only to the SBC application.

'Syslog Optimization'

configure troubleshoot > syslog > syslog-optimization

[SyslogOptimization]

Enables the device to accumulate and bundle multiple debug messages into a single UDP packet and then send it to a syslog server. The benefit of this feature is that it reduces the number of UDP syslog packets, thereby improving (optimizing) CPU utilization.

[0] Disable (default)
[1] Enable

Note: The size of the bundled message is configured by the [MaxBundleSyslogLength] parameter.

configure voip > gateway digital settings > mx-syslog-lgth

[MaxBundleSyslogLength]

Defines the maximum size (in bytes) threshold of logged syslog messages bundled into a single UDP packet, after which they are sent to a syslog server.

The valid value range is 0 to 1220 (where 0 indicates that no bundling occurs). The default is 1220.

Note: The parameter is applicable only if the [GWDebugLevel] parameter is enabled.

'Syslog CPU Protection'

configure troubleshoot > syslog > syslog-cpu-protection

[SyslogCpuProtection]

Enables the protection of the device's CPU resources during debug reporting, ensuring voice traffic is unaffected. If CPU resources drop (i.e., high CPU usage) to a critical level (threshold), the device automatically lowers the debug level to free up CPU resources that were required for the previous debug-level functionality. When sufficient CPU resources become available again, the device increases the debug level. The threshold is configured by the 'Debug Level High Threshold' parameter (see below).

[0] Disable
[1] Enable (default)

'Debug Level High Threshold'

configure troubleshoot > syslog > debug-level-high-threshold

[DebugLevelHighThreshold]

Defines the threshold (in percentage) for automatically switching to a different debug level, depending on CPU usage. The parameter is applicable only if the 'syslog CPU Protection' parameter is enabled.

The valid value is 0 to 100. The default is 90.

The debug level is changed upon the following scenarios:

CPU usage equals threshold: Debug level is reduced one level.
CPU usage is at least 5% greater than threshold: Debug level is reduced another level.
CPU usage is 5 to 19% less than threshold: Debug level is increased by one level.
CPU usage is at least 20% less than threshold: Debug level is increased by another level.

For example, assume that the threshold is set to 70% and the Debug Level to Detailed (5). When CPU usage reaches 70%, the debug level is reduced to Basic (1). When CPU usage increases by 5% or more than the threshold (i.e., greater than 75%), the debug level is disabled - No Debug (0). When the CPU usage decreases to 5% less than the threshold (e.g., 65%), the debug level is increased to Basic (1). When the CPU usage decreases to 20% less than the threshold (e.g., 50%), the debug level changes to Detailed (5).

Note: The device doesn't increase the debug level to a level that is higher than what you configured for the 'Debug Level' parameter.

configure troubleshoot > cdr > time-zone-format

[TimeZoneFormat]

Defines the time zone that is displayed with the timestamp in CDRs. The timestamp appears in the CDR fields "Setup Time", "Connect Time", and "Release Time".

The valid value is a string of up to six characters. The default is UTC. For example, if you configure the parameter TimeZoneFormat = GMT+11, the timestamp in CDRs are generated with the following time zone display:

17:47:45.411 GMT+11 Sun Jan 03 2018

Note: The time zone is only for display purposes; it doesn't configure the actual time zone.

configure troubleshoot > cdr > call-duration-units

[CallDurationUnits]

Defines the unit of measurement for call duration ("Duration" field) in CDRs generated by the device.

[0] Seconds (default)
[1] Deciseconds
[2] Centiseconds
[3] Milliseconds

The parameter applies to CDRs for syslog, RADIUS, local-device storage, and CDR history displayed in the Web interface.

'CDR Syslog Sequence Number'

configure system > cdr > cdr-seq-num

[CDRSyslogSeqNum]

Enables or disables the inclusion of the sequence number (S=) in CDR Syslog messages.

[0] Disable
[1] Enable (default)

configure voip > sip-definition settings > send-acsessionid

[SendAcSessionIDHeader]

Enables the use of the Global Session ID in SIP messages (AC-Session-ID header), which is a unique identifier of the call session, even if it traverses multiple devices.

[0] = (Default) Disables the feature. The device sends outgoing SIP messages without a Global Session ID (even if a Global Session ID was received in the incoming SIP message).
[1] = Enables the feature. If the device receives an incoming SIP message containing a Global Session ID, it sends the same Global Session ID in the outgoing SIP message. If the incoming SIP message doesn't contain a Global Session ID or if a new session is initiated by the device, the device generates a new, unique Global Session ID and adds it to the outgoing SIP message.

For more information, see Enabling Same Call Session ID over Multiple Devices.

'Activity Types to Report via Activity Log Messages'

configure troubleshoot > activity-log

[ActivityListToLog]

Defines the operations (activities) performed in the Web interface that are reported to a syslog server.

[PVC] Parameters Value Change = Changes made on-the-fly to parameters and tables, and Configuration file upload. Note that the ini file parameter, EnableParametersMonitoring can also be used to set this option.
[AFL] Auxiliary Files Loading = Loading of Auxiliary files.
[DR] Device Reset = Restarting the device from the Maintenance Actions page.
Note: For this option to take effect, a device restart is required.
[FB] Flash Memory Burning = Saving configuration with save to flash from the Maintenance Actions page.
[SWU] Device Software Update = Software updates (i.e., loading of cmp file) through the Software Upgrade Wizard.
[NAA] Non-Authorized Access = Attempts to log in to the Web interface with a false or empty username or password.
[SPC] Sensitive Parameters Value Change = Changes made to "sensitive" parameters:
(1) IP Address
(2) Subnet Mask
(3) Default Gateway IP Address
(4) ActivityListToLog
[LL] Login and Logout = Web login and logout attempts.
[CLI] CLI Activity = CLI commands entered by the user.
[AE] Action Executed = Logs user actions that are not related to parameter changes. The actions can include, for example, file uploads, file downloads, file delete, lock-unlock maintenance actions, LDAP clear cache, register-unregister, and start-stop trunk. In the Web, these actions are typically done by clicking a button (e.g., the LOCK button).
[INI] Incremental INI = Changes made to parameters due to the loading of an incremental ini file. If you choose this option, you can also define the maximum number of lines of parameters to log from the ini file, using the 'Incremental INI Activity Logs Max Number' parameter (see below).

Note: For the ini file parameter, enclose values in single quotation marks. To configure the ini file parameter with multiple values, use a comma-separated list, for example: ActivityListToLog = 'PVC', 'AFL', 'DR'.

'Incremental INI Activity Logs Max Number'

configure troubleshoot > max-ini-activity-logs

[MaxINIActivityLog]

Defines the maximum number of lines of parameters from the loaded incremental ini file to log for the Activity Types to Report feature. The parameter is applicable when you configure the [ActivityListToLog] parameter to also include the INI value.

The valid value is 0 to 2,000. The default is 1,000.

Note: The maximum number of lines doesn't count empty lines or lines containing only comments.

[EnableParametersMonitoring]

Enables the monitoring, through syslog messages, of parameters that are modified on-the-fly.

[0] = (Default) Disable
[1] = Enable

'Destination IP Address'

configure troubleshoot > logging settings > dbg-rec-dest-ip

[DebugRecordingDestIP]

Defines the IP address (IPv4 or IPv6) of the server for capturing debug recording.

'Destination Port'

configure troubleshoot > logging settings > dbg-rec-dest-port

[DebugRecordingDestPort]

Defines the UDP port of the server for capturing debug recording.

The default is 925.

'Maximum duration'

configure troubleshoot > logging settings > dbg-rec-timeout

[DebugRecordingTimeout]

Defines the maximum duration (in minutes) for the debug recording process. When this timer expires, the device automatically stops debug recording (unless you've explicitly stopped it before the timer expires, as described in Starting and Stopping Debug Recording).

The valid value is 1 to 10,080 (7 days). The default is 60 (1 hour).

Note: If debug recording is currently running (i.e., was started), the device resets the debug recording timer upon the following:

A new rule is added to, or an existing rule is modified in the Logging Filters table.
A device restart.

'Start' / 'Stop'

configure troubleshoot > logging-settings > dbg-rec-status

[DebugRecordingStatus]

Starts or stops debug recording.

For more information on starting and stopping debug recording, see Starting and Stopping Debug Recording.

Note: The CLI command also displays the current debug recording status (Started or Stopped), and resets the debug recording timer (configured by the [DebugRecordingTimeout] parameter).

'Interface Name'

configure troubleshoot > logging settings > dbg-rec-int-name

[DebugRecordingIpInterfaceName]

Defines the IP Interface through which the device sends captured traffic to the debug server.

The valid value is the name of the IP Interface, as configured in the IP Interfaces table (see Configuring IP Network Interfaces). The default is the OAMP interface.

'Enable Core Dump'

enable-core-dump

[EnableCoreDump]

Enables the automatic generation of a Core Dump file upon a device crash.

[0] Disable (default)
[1] Enable

'Core Dump Destination IP'

core-dump-dest-ip

[CoreDumpDestIP]

Defines the IP address of the remote server where you want the device to send the Core Dump file.

By default, no IP address is defined.

'Call Flow Report Mode'

call-flow-report

[CallFlowReportMode]

Enables the device to send SIP call messages to OVOC so that OVOC can display SIP call dialog sessions as SIP call flow diagrams.

[0] Disable (default)
[1] Enable

For more information, see Enabling SIP Call Flow Diagrams in OVOC.

configure troubleshoot > syslog > system-log-size

[SystemLogSize]

Defines the maximum size (in kilobytes) of the system log file.

The valid value range is 10 to 2000 KB. The default is 200 KB.

To view the logged information in this file, use the CLI command show system log.

[PLThresholdLevelsPerMille]

Defines packet-loss percentage ranges that are used in sent syslog messages to report packet loss in incoming media streams (RTP) in 15-second intervals.

The valid value range is 1 to 1,000. The default is 5, 10, 20, 50.

The syntax for configuring the parameter is: PLThresholdLevelsPerMille = Level1, Level2, Level3, Level4

Where the levels represent the following ranges in the syslog:

[No PL]
[up to (Level1/10)% ]
[(Level1/10)% - (Level2/10)%]
[(Level2/10)% - (Level3/10)%]
[(Level3/10)% - (Level4/10)%]
[(Level4/10)% - 100%]

For example (using default values):

PLThresholdLevelsPerMille = 5,10,20,50

Therefore, the ranges are:

[No PL]
[up to 0.5% ]
[0.5% - 1%]
[1% - 2%]
[2% - 5%]
[5% - 100%]

For more information, see Packet Loss Indication in Syslog.

CDR Local Storage

'File Size'

configure troubleshoot > cdr > file-size

[CDRLocalMaxFileSize]

Defines the size (in kilobytes) of each locally stored CDR file. When the Current file reaches this size, the device creates a CDR file containing all the CDRs from the Current file.

The valid value is 100 to 10,000. The default is 1024.

Note:

CDR file creation works together with the 'Rotation Period' parameter, whereby the file is created as soon as one of the parameter's ('File Size' or 'Rotation Period') settings are fulfilled (whichever is met earlier). For example, if the 'File Size' parameter is 100 and 'Rotation Period' is 60, and the file size reaches 100 kbytes after only 30 minutes has passed, the device creates the CDR file.
The parameter is applicable only to local storage of CDRs.

'Number of Files'

configure troubleshoot > cdr > files-num

[CDRLocalMaxNumOfFiles]

Defines the maximum number of locally stored CDR files. If the maximum number is reached and a new file is created, the oldest file is deleted to make space for the new file (i.e., FIFO).

The valid value is 2 to 4096 . The default is 5.

Note: The parameter is applicable only to local storage of CDRs.

'Rotation Period'

configure troubleshoot > cdr > rotation-period

[CDRLocalInterval]

Defines how often (in minutes) the device creates a new CDR file for locally stored CDRs. For example, if configured to 60, every hour it creates a CDR file containing all the CDRs from the Current file.

The valid value is 2 to 1440. The default is 60.

Note:

CDR file creation works together with the 'File Size' parameter, whereby the file is created as soon as one of the parameter's ('File Size' or 'Rotation Period') settings are fulfilled (whichever is met earlier). For example, if the 'Rotation Period' parameter is 60 and 'File Size' is 100, and an hour has passed but the file size is only 50 kbytes, the device creates the CDR file.
The CDR file is created even if there are no CDRs in the Current file.
The parameter is applicable only to local storage of CDRs.

IP Trace Filters (For more information, see Filtering IP Network Traces by Ethernet Port or VLAN.)

'Recording Mode'

configure troubleshoot > logging settings > dbg-rec-ip-trace-entity

[DebugRecordingIpTraceEntity]

Defines the filtering of IP traces for log filtering rules (in the Logging Filters table) whose 'Filter Type' parameter is configured to IP Trace.

[0] All Physical Ethernet Ports = (Default) The log filter for the IP trace is applied on packets received and sent (tagged and untagged) on all the physical Ethernet ports.
[1] Physical Ethernet Port = The log filter for the IP trace is applied on packets received and sent on an Ethernet port configured by the 'Physical Ethernet Port' parameter (below).
[3]VLAN ID = The log filter for the IP trace is applied on packets received and sent on a VLAN ID (underlying Ethernet Device) configured by the 'VLAN ID' parameter (below).

'Physical Ethernet Port'

configure troubleshoot > logging settings > dbg-rec-ip-trace-phy-port

[DebugRecordingIpTracePhysicalPort_IpTracePhyPort]

Filters IP traces by a specific Ethernet port.

'VLAN ID'

configure troubleshoot > logging settings > dbg-rec-ip-trace-vlan-id

[DebugRecordingIpTraceVlanId_IpTraceVlanId]

Filters IP traces by a specific VLAN ID.

PII Masking (GDPR)

'Mask Digits'

configure voip > sip-definition settings > pii-mask-digits

[PIIMaskDigits]

Enables the masking of DTMF and other digits detected by the device in the generated syslog messages and debug recording.

[0] Disable (default)
[1] Enable

For more information, see Masking Digits in Syslog Messages.

'Mask PII in CDRs'

configure voip > sip-definition settings > pii-mask-private-info-in-cdrs

[PIIMaskPrivateInfoInCDRs]

 

Enables the masking of personally identifiable information (PII) in CDRs generated by the device.

[0] Disable = No masking is done.
[1] Mark PII in Web or CLI = The device masks (by a single asterisk * symbol) private information (caller and callee) in the Web interface’s SBC CDR History table (see Viewing CDR History of SBC and Test Calls) and Gateway CDR History table (see Viewing Gateway CDR History), and CLI (e.g., show voip calls). For example, the device masks the URI "name@domain.com" as "*".
[2] Mask PII in Detailed Records = The device masks (by multiple asterisks *) private information in CDRs and SDRs. This applies to all destinations to where the device sends these records (i.e., syslog, REST, Local Storage, and RADIUS), except ARM and OVOC. This option also affects PII in the Web interface’s SBC CDR History table Gateway CDR History table, and CLI (e.g., show voip calls). For URIs, only the user part is masked.

For more information, see Masking PII in CDRs.

'Number of Unmasked Characters in PII'

configure voip > sip-definition settings > pii-number-of-unmasked-chars

[PIINumberOfUnmaskedChars]

Defines the number of characters in the PII element to show when the 'Mask PII in CDRs' parameter is configured to Mask PII in Detailed Records. The rest of the characters are masked (each by an asterisk sign).

The valid value is 0 to 255. The default is 0 (masks all characters).

For more information, see Masking PII in CDRs.

'Location in PII of Unmasked Characters'

configure voip > sip-definition settings > pii-unmasked-chars-location

[PIIUnmaskedCharsLocation]

 

Defines from where in the PII element to show the number of characters specified by the 'Number of Unmasked Characters in PII' parameters, when the Mask Private Information in CDRs' parameter is configured to Mask PII in Detailed Records.

[0] Last Characters = (Default) The device shows the number of characters specified by the 'Number of Unmasked Characters in PII' parameter, starting from the end of the PII element.
[1] First Characters = The device shows the number of characters specified by the 'Number of Unmasked Characters in PII' parameter, starting from the beginning of the PII element.

For more information, see Masking PII in CDRs.

'Mask PII in QoE CDRs for OVOC'

configure voip > sip-definition settings > pii-mask-private-info-for-ovoc

[PIIMaskPrivateInfoForOVOC]

Enables the PII masking (with asterisks) of phone numbers, URI user parts, and display names in CDRs that the device sends to OVOC.

[0] Disable (default)
[1] Enable

For more information, see Masking PII in CDRs.

'Mask URI Host Part in CDRs'

configure voip > sip-definition settings > pii-mask-host

[PIIMaskHost]

Enables the PII masking (with asterisks) of URI host parts (including IP addresses) in CDRs that the device sends to Web, CLI, syslog, REST, RADIUS, and Local Storage (depending on which targets are anonymized by the 'Mask PII in CDRs' parameter), or to OVOC if the 'Mask PII in QoE CDRs for OVOC' parameter is enabled.

[0] Disable (default)
[1] Enable

For more information, see Masking PII in CDRs.